Integrate Splicing with Quiescence #4019
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4019 +/- ##
==========================================
- Coverage 88.76% 88.76% -0.01%
==========================================
Files 176 176
Lines 128139 128185 +46
Branches 128139 128185 +46
==========================================
+ Hits 113743 113777 +34
- Misses 11822 11828 +6
- Partials 2574 2580 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
TheBlueMatt
force-pushed
the
2025-08-splice-quiescent-real
branch
from
be3b93a to
ddb3b37
Compare
lightning/src/ln/channel.rs
Outdated
| let tx16 = TransactionU16LenLimited::new(tx) | ||
| .map_err(|_e| APIError::APIMisuseError { err: format!("Too large transaction") })?; | ||
|
|
||
| // TODO(splicing): Check that transactions aren't too big for the splice_init message here. |
There was a problem hiding this comment.
We probably just want to do all input validation here before we even attempt quiescence so that we can fail early and fast. No point in going through the whole stfu dance just to immediately fail back to the user with "insufficient fees" or something similar.
There was a problem hiding this comment.
Yep, that's definitely the goal. Kinda leaving this until the parameters are clear and I'll clean it up then.
|
👋 Thanks for assigning @jkczyz as a reviewer! |
When doing an outbound splice, we check some of the instructions first in utility methods, then convert errors to `APIError`s. These utility methods should thus either return an `APIError` or more generic (string or `()`) error type, but they currently return a `ChannelError`, which is only approprite when the calling code will do what the `ChannelError` instructs (including closing the channel). Here we fix that by returning `String`s instead.
Now that we have a `QuiescentAction` to track what we intend to do once we reach quiescence, we need to use it to initiate splices. Here we do so, adding a new `SpliceInstructions` to track the arguments that are currently passed to `splice_channel`. While these may not be exactly the right arguments to track in the end, a lot of the splice logic is still in flight, so we can worry about it later.
While we have a test to disconnect a peer if we're waiting on an `stfu` message, we also disconnect if we've reached quiescence but we're waiting on a peer to do "something fundamental" and they take too long to do so. We test that behavior here.
TheBlueMatt
force-pushed
the
2025-08-splice-quiescent-real
branch
from
ddb3b37 to
d9a278c
Compare
wpaulino
requested review from
jkczyz
and removed request for
valentinewallace
Based on #4007this does the actual integration. Will probably go after #3979 so drafting for now.